在依据 Electron 的使用中，有一个业务需求是获取物理网卡的 Mac 地址以用于客户机唯一性识别。

刚接到需求时你或许会想，这还不简单，调用 Node.js 的 os 模块提供的 networkInterfaces API 就行了。所以立刻开干：

两分钟就写完了，测验一下返回值也与 ipconfig/ifconfig 打印的信息一致，满怀信心的提交代码完工。

测验同学当天验证了一下表示没什么问题，然而第二天却找上门了：同一台电脑今昨两天取到的值不一样。经过各种排查剖析，最终才发现本来这位测验妹妹因疫情管控居家了，用着 VPN 长途接入工作网络干活呢。

本来开 VPN 的时分使用了虚拟网卡，此时你才发现工作并没有那么简单。实际上，在存在 VPN、虚拟机等场景下，都或许会使用到虚拟网卡。

networkInterfaces 能够获取到一切网卡的基本信息，可依据 internal、mac 等字段的值做一次过滤，得到有用的信息：

可是对于 VPN、虚拟机等存在虚拟网卡的场景下，仅依据该信息无法进行有用区分。

如果能够得到虚拟网卡的特征，则可依据相关特征点进行识别与过滤。

依据某内部项目长达六年的实践积累以及参阅 vscode 中类似的完成，咱们得到了一个常见虚拟网卡默许 Mac 地址特征的列表，参阅如下：

所以能够据此完成一个是否为虚拟网卡的判断办法 isVirtualMac：

据此可对 getMac 办法改进如下：

在 Windows 体系下，能够经过执行 ipconfig /all 或 wmic nic get 命令得到一切网卡的概况，其中包含了描绘信息。

依据实践经验剖析，咱们总结了一个常见虚拟网卡描绘关键字的特征列表，参阅如下：

若经过前述规矩过滤之后仍然存在多个网卡信息，则可持续获取网卡概况，并依据 virtualDescList 列表以测验进一步的过滤处理：

getNetworkIFacesInfoByWmic 办法的详细完成能够拜见这儿：

github.com/lzwme/get-p…

过滤办法会将视为无效的项扫除，可是或许会因规矩的误差而导致最终得到的列表为空。为了防止这种或许现象的出现，能够将过滤扫除改为优先级排序办法，最终取列表第一项视为最优选项。

排序办法完成示例：

所以最终的逻辑大致如下：

实际上社区里已经有 address、getmac和macaddress 等较为流行的相关库，但它们都不触及虚拟网卡的识别。 本文主要介绍了依据实践经验对虚拟网卡的识别处理办法，与 vscode 中的相关完成逻辑较为类似，但又增加了依据描绘信息过滤的规矩逻辑。